The present invention relates to a method, apparatuses and a system for controlling header compression and decompression in a packet data network, as for example an IP (Internet Protocol) based network.
In communication networks using packet data transport, individual data packets carry in a header section an information needed to transport the data packet from a source application to a destination application. The actual data to be transmitted is contained in a payload section.
The transport path of a data packet from a source application to a destination application usually involves multiple intermediate steps represented by network nodes interconnected through communication links. These network nodes, called packet switches or routers, receive the data packet and forward it to a next intermediate router until a destination network node is reached which will deliver the payload of the data packet to the destination application. Due to contributions of different protocol layers to the transport of the data packet, the length of a header section of a data packet may even exceed the length of the payload section.
Data compression of the header section may therefore be employed to obtain better utilization of the link layer for delivering the payload to a destination application. Header compression reduces the size of a header by removing header fields or by reducing the size of header fields. This is done in a way such that a decompressor can reconstruct the header if its context state is identical to the context state used when compressing the header. Header compression may be performed at network layer level (e.g. for IP headers), at transport layer level (e.g. for User Datagram Protocol (UDP) headers or Transport Control Protocol (TCP) headers), and even at application layer level (e.g. for Hyper Text Transport Protocol (http) headers).
In the IETF (Internet Engineering Task Force) specification RFC 3095, a robust header compression (ROHC) scheme is specified as a highly robust and efficient header compression scheme for RTP/UDP/IP (Real Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. During the last years, two communication technologies in particular have become commonly used by the general public: cellular telephony and the Internet. Cellular telephony has provided its users with the revolutionary possibility of always being reachable with reasonable service quality no matter where they are. The Internet, on the other hand, has from the beginning being designed for multiple services and its flexibility for all kinds of usage has been one of its strength. IP telephony is gaining momentum thanks to improved technical solutions. Cellular phones have become more general-purpose, and may have IP stacks supporting not only audio and video, but also web-browsing, e-mail, gaming, etc. Thus, two mobile terminals communicating with each other may be connected to base stations over cellular links, and the base stations may be connected to an IP-based wired network. If technically and economically feasible, a solution with pure IP all the way from terminal to terminal would have certain advantages. However, to make this a viable alternative, a number of problems have to be addressed, in particular problems regarding bandwidth efficiency.
For cellular phone systems, it is of vital importance to use the scarce radio resources in an efficient way. A sufficient number of users per cell are crucial, otherwise deployment costs will be prohibitive. The quality of the voice service should also be as good as in today's cellular systems. It is likely that even with support for new services, lower quality of the voice service is acceptable only if costs are significantly reduced.
A problem with IP over cellular links when used for interactive voice conversations is the large header overhead. Thus, the need for reducing header sizes for efficiency reasons is obvious. However, cellular links have characteristics that make header compression perform less than well. A viable header compression scheme for cellular links must be able to handle loss on the link between the compression and decompression point as well as loss before the compression point.
The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as “context”, when it is clear which is intended. The context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet stream is also part of the context, for example information about how the IP identifier field changes and the typical inter-packet increase in sequence numbers or time stamps.
Generally, a packet corresponds to a unit of transmission and reception, e.g. a protocol data unit. The packet is compressed and then decompressed e.g. by ROHC. The packet stream corresponds to a sequence of packets where the field values and change patterns of field values are such that the headers can be compressed using the same context. When the context of the decompressor is not consistent with the context of the compressor, decompression may fail to reproduce the original header. This situation may occur when the context of the decompressor has not been initialized properly or when packets have been lost or damaged between compressor and decompressor. Context repair mechanisms are mechanisms which bring the contexts in synchronization when they were not. This is needed to avoid excessive loss due to context damage.
The main reason why header compression can be done at all is the fact that there is significant redundancy between header fields, both within the same packet header but in particular between consecutive packets belonging to same packet stream. By sending static field information only initially and utilizing dependencies and predictability for other fields, the header size can be significantly reduced for most packets. Relevant information from past packets is then maintained in the context. The context information is used to compress or decompress subsequent packets. The compressor and decompressor update their contexts upon certain events. Contexts are identified by a context identifier (CID) which is sent along with compressed headers and feedback information. The feedback information carries information from the decompressor to the compressor. An acknowledgement information (ACK) is used to acknowledge successful decompression of a packet, which means that the context is up-to-date with a high probability. Furthermore, a non-acknowledgement information (NACK) is used to indicate that the dynamic context of the decompressor is out of synchronization. This feedback information is generated when several successive packets have failed to be decompressed correctly.
The ROHC header compression scheme has three modes of operation, called unidirectional mode (U-mode), bi-directional optimistic mode (O-mode), and bi-directional reliable mode (R-mode). The optimal mode to operate in depends on the characteristics of the environment of the compression protocol, such as feedback abilities, error probabilities and distributions, effects of header size variation, etc.
When in the U-mode, packets are sent in one direction only, from the compressor to the decompressor. This mode is therefore usable over links where a return path from decompressor to compressor is unavailable or undesirable. In the U-mode, transitions between compressor states are performed only on account of periodic timeouts and irregularities in the header field change patterns in the compressed packet stream. Due to the periodic refreshes and the lack of feedback for initiation of error recovery, compression in the U-mode will be less efficient and have a slightly higher probability of loss propagation compared to any of the bi-directional modes. Compression with ROHC must start in the U-mode. Transition to any of the bi-directional modes can be performed as soon as a packet has reached the decompressor and it has replied with a feedback packet indicating that a mode transition is desired.
The O-mode is similar to the U-mode. The difference is that a feedback channel is used to send error recovery requests and optionally acknowledgements of significant context updates from decompressor to compressor. Periodic refreshes are not used in the O-mode. The O-mode aims to maximize compression efficiency and sparse usage of the feedback channel. It reduces the number of damaged headers delivered to the upper layers due to residual errors or context invalidation.
Finally, the R-mode differs in many ways from the previous two modes. The most important differences are a more intensive usage of the feedback channel and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between compressor and decompressor except for very high residual bit error rates. Feedback is sent to acknowledge all context updates. The R-mode aims to maximize robustness against loss propagation and damage propagation, i.e. minimize the probability of context invalidation, even under header loss/error burst conditions.
ROHC is designed under the assumption that packets can be damaged between the compressor and the decompressor, and that such damaged packets can be delivered to the decompressor. ROHC detects damaged headers using cyclic redundancy check codes (CRCs) over the original headers. In the U- and O-modes, the smallest headers include a 3-bit CRC, while in the R-mode the smallest headers do not include a CRC. Thus, damage to the smallest headers is not detected in the R-mode. When working in the U-mode, all compressed headers carry a CRC which must be used to verify decompression. In the R-mode the following feedback logic is used by the decompressor. When an updating packet, i.e. a packet carrying a 7- or 8-bit CRC, is correctly decompressed, an acknowledgement (ACK(R)) with a mode parameter indicating the R-mode as the desired compression mode is sent to the compressor. On the other hand, no feedback is sent for packets not updating the context, i.e., packets that do not carry a CRC.
The decision to move from one compression mode to another is taken by the decompressor. For each context, the compressor and the decompressor maintain a variable whose value is the current compression mode and decompression mode, respectively, for that context. The value of this variable controls, for the context in question, which packet types to use, which actions to be taken, etc. At the compressor side, parameters C_MODE and C_TRANS are provided. Possible values for the C_MODE parameter are “U” for unidirectional, “O” for optimistic, and “R” for reliable. The parameter C_MODE must be initialized to “U”. Furthermore, possible values for the parameter C_TRANS are “P” for pending and “D” for done. The parameter C_TRANS must be initialized to “D”. When the parameter C_TRANS is set to “P”, it is required that the compressor only use packet formats common to all modes, that a mode information is included in packets sent, at least periodically, and that new mode transition requests be ignored.
At the decompressor side, parameters D_MODE and D_TRANS are provided. Possible values for the parameter D_MODE are “U” for unidirectional, “O” for optimistic and “R” for reliable. The parameter D_MODE must be initialized to “U”. Furthermore, possible values for the parameter D_TRANS are “I” for initiated, “P” for pending, and “D” for done. The parameter D_TRANS must be initialized to “D”. A mode transition can only be initiated when the parameter D_TRANS is set to “D”. While the parameter D-TRANS is set to “I”, the decompressor sends a non-acknowledgement (NACK) or an acknowledgement (ACK) carrying a CRC option for each received packet.
Due to increased sizes of IP address fields, an IP header extension has been introduced to IP headers to minimize the changes necessary for supporting IP address extensions. However, when an incoming packet has a large IP extension header, the compressor and the decompressor may loose consistency between each other due to e.g. context damage, which will lead to compression and/or decompression failure. For example, context damage may result if the compressor compresses a larger IP extension header list than the decompressor is prepared to store, due to the fact that the decompressor has not allocated sufficient memory for the maximum sized IP extension header list. When the context damage happens, it may take a long time to repair the context, while during this period many packets are discarded due to incorrect decompression. An uncompressed packet type is then used to bring the context in synchronization again which causes low compression efficiency. According to another solution, sufficient memory for the maximum sized IP extension header list can be allocated to the decompressor. This will however result in huge memory uses, since the maximum size of the IP extension header list is the same as the maximum input packet size.